home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group99a.txt / 000231_icon-group-sender _Wed Nov 10 09:48:02 1999.msg < prev    next >
Internet Message Format  |  2000-09-20  |  4KB
  1. Return-Path: <icon-group-sender>
  2. Received: (from root@localhost)
  3.     by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id JAA29359
  4.     for icon-group-addresses; Wed, 10 Nov 1999 09:47:40 -0700 (MST)
  5. Message-Id: <199911101647.JAA29359@baskerville.CS.Arizona.EDU>
  6. X-Authentication-Warning: agate.berkeley.edu: news set sender to <news> using -f
  7. From: Steve Wampler <swampler@noao.edu>
  8. X-Newsgroups: comp.lang.icon
  9. Subject: Re: List question
  10. Date: Wed, 10 Nov 1999 08:44:04 -0700
  11. X-Trace: noao.edu 942248646 36323 140.252.38.6 (10 Nov 1999 15:44:06 GMT)
  12. X-Complaints-To: abuse@noao.edu
  13. X-Accept-Language: en
  14. To: icon-group@optima.CS.Arizona.EDU
  15. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  16. Status: RO
  17.  
  18. Anders Holtsberg wrote:
  19. > 
  20. > Sorry folks. I just found the very recent discussion on
  21. > this topic on Dejanews. But still: why not let
  22. > 
  23. >     mylist[5+:0] := anotherlist
  24. > 
  25. > be a legal construct? I e the only change would be to
  26. > let mylist[i:j] produce an l-value instead of an r-value,
  27. > it would break no code at all, would it?
  28.  
  29. Correct, this change should have no impact on existing code.
  30.  
  31. > Is the implementation difficult? Are there filosophical
  32. > or implementation problems? (I'm not nagging you guys: I can
  33. > try to do the work if you think the change in semantics is OK).
  34.  
  35. I imagine others will disagree, but I'd like to see at least
  36. an experimental version of Icon with this change in it.  I
  37. assume Anders means to differentiate list sectioning from
  38. list subscripting and have any list section produce an l-value.
  39. This change would bring us one step closer to providing list-scanning.
  40. In fact, it would be possible to then produce a PDCO to experiment
  41. with list-scanning.
  42.  
  43. However, it does require a non-trivial implementation - you'd have
  44. to essentially reproduce internally the same types of operations
  45. that people now have to use externally (though you could apply some
  46. heuristics).
  47.  
  48. For example, implementing:
  49.  
  50.    a[3:5] := [a,b,c,d]
  51.  
  52. would require producing a new list, as if the user had done:
  53.  
  54.    a := a[1:3] ||| [a,b,c,d] ||| a[5:0]
  55.  
  56. (because list element storage is sequential in memory) thus adding
  57. a single element in the middle of a list could have surprisingly
  58. high runtime cost. It has this cost currently, but the fact that
  59. the user has to explicitly code it means it's not a surprise...
  60.  
  61. On the other hand:
  62.  
  63.    a[3:5] := []
  64.  
  65. could (possibly, depending on the desired semantics, see below) be done in
  66. place on the original list, as could a[3:5] := [1] and a[3:5] := [1,2].
  67.  
  68. There are also a few major semantic issues to resolve.  How close to the
  69. behavior
  70. of strings should list section assignment go?  Strings and lists have some
  71. fundamental differences that should be considered carefully.  In particular,
  72. note that, depending on the implementation, there could be a major difference
  73. between
  74.  
  75.    a[3:5] := [a,b,c,d]
  76.  
  77. and
  78.  
  79.    a := a[1:3] ||| [a,b,c,d] ||| a[5:0]
  80.  
  81. (Suppose the assignment b := a is done prior to each of the above
  82. statements. What should the value of b be?).  So list section
  83. assignment does mean that programmers would have to think very carefully
  84. about how they are using lists.  Of course, this is true currently; the
  85. following code catches people sometimes...
  86.  
  87.     a := [1,2,3,4]
  88.     b := a
  89.     a[2] := 5
  90.  
  91. Extending the above behavior to list sectioning is where the direct
  92. implementation becomes complicated.  You'd have to change how lists are
  93. represented and provide "list qualifiers" much as strings are
  94. implemented using string qualifiers.
  95.  
  96. Altering the semantics of list processing to provide even closer semantics
  97. to string processing would be very difficult to implement and would
  98. break existing code (because if you're going to "fix" list sectioning
  99. this way, you'd want to also "fix" list element assignment as well).
  100. I don't think I would be very keen on that drastic of a change.
  101.  
  102. --
  103. Steve Wampler-  SOLIS Project, National Solar Observatory
  104. swampler@noao.edu
  105.